Libris Britannia 4

home *** CD-ROM | disk | FTP | other *** search

/ Libris Britannia 4 / science library(b).zip / science library(b) / COMMUNIC / BULLETIN / 0340A.ZIP / ODOC_000.ARC / OPUS_SYS.DOC next >

Wrap

Text File | 1987-01-06 | 149.3 KB | 3,528 lines

############ ## ## ## ## ## ## ######## ## ## ####### ## ## ## ## ## ## ## ## ## ## ## ## ## ####### ## ## ## ## ## ## ## ############ ######## ######### ####### ## ## ## ## ---------------------------------- Computer-Based Conversation System by Wynn Wagner III Matrix 124/108 ---------------------------------- Questions regarding Opus should be directed to: OPUSinfo Here modem (214) 991-3381 1/113 OPUSinfo There modem (415) 753-3356 1/114 OPUS - Copyright (c) 1986, 1987 by Wynn Wagner III All rights reserved OPUS is militantly public domain. This means you may NOT sell OPUS or any part of it to anybody for any reason.If you do, then you are required to make a contribution of $50 to: The Shanti Project 896 Hayes Street San Francisco, CA 94117 Attn: Director of Development Please mention that your contribution is for OPUS. Hopefully, the contribution will be tax-deductible -- you will receive an acknowledgement directly from The Shanti Project. "It was the Law of the Sea, they said. Civilization ends at the waterline. Beyond that, we all enter the food chain, and not always right at the top." --- Hunter S. Thompson Documentation by David Finster, Mike Kelleher, Mike Elkins, Wynn Wagner, and Jon Sabol. TABLE OF CONTENTS INTRODUCTION What's an "OPUS?" . . . . . . . . . . . . . . . . . . . 1 About This Document . . . . . . . . . . . . . . . . . . 1 What does OPUS really mean? . . . . . . . . . . . . . . 2 The Rules for Using OPUS . . . . . . . . . . . . . . . 2 The Rules on Transferring OPUS Software . . . . . . . . 2 List of Things Borrowed, not Blue . . . . . . . . . . . 3 Legal Stuff . . . . . . . . . . . . . . . . . . . . . . 3 Version Numbers . . . . . . . . . . . . . . . . . . . . 4 OVERVIEW Equipment . . . . . . . . . . . . . . . . . . . . . . . 5 Hardware . . . . . . . . . . . . . . . . . . . . . 5 Software . . . . . . . . . . . . . . . . . . . . . 5 CONFIG.SYS File . . . . . . . . . . . . . . . 6 FILES=xx . . . . . . . . . . . . . . . . 6 BUFFERS=xx . . . . . . . . . . . . . . . 6 COUNTRY=xxx . . . . . . . . . . . . . . 6 DEVICE=ANSI.SYS . . . . . . . . . . . . 7 AUTOEXEC.BAT . . . . . . . . . . . . . . . . 7 OPUS!Comm . . . . . . . . . . . . . . . 7 Set TZ= . . . . . . . . . . . . . . . . 8 Functional Overview . . . . . . . . . . . . . . . . . . 9 The Matrix . . . . . . . . . . . . . . . . . . . . 9 Messages . . . . . . . . . . . . . . . . . . . . . 9 Local Messages . . . . . . . . . . . . . . . 9 Matrix Messages . . . . . . . . . . . . . . . 9 Broadcast Messages . . . . . . . . . . . . . 10 File Section . . . . . . . . . . . . . . . . . . . 10 Uploads . . . . . . . . . . . . . . . . . . . 10 Downloads . . . . . . . . . . . . . . . . . . 10 Matrix . . . . . . . . . . . . . . . . . . . 10 Operating Philosophy . . . . . . . . . . . . . . . . . 11 Differences Between OPUS and FIDO<tm> . . . . . . . . . 11 File Structures . . . . . . . . . . . . . . . . . 11 Extended Display File Capability . . . . . . . . . 12 Extended File Transfer Protocols . . . . . . . . . 13 EchoMail Enhancements . . . . . . . . . . . . . . 13 Mail Interface . . . . . . . . . . . . . . . . . . 13 Extended Message Area Attributes . . . . . . . . . 14 Message Area Commands . . . . . . . . . . . . . . 14 File Area Commands . . . . . . . . . . . . . . . . 15 Miscellaneous Commands . . . . . . . . . . . . . . 16 OPUS Sysop Manual - Page i THE MESSAGE SECTION What is a Message Section? . . . . . . . . . . . . . . 17 Setting up a Message Section . . . . . . . . . . . . . 17 System Files . . . . . . . . . . . . . . . . . . 17 Creating a System File . . . . . . . . . . . 17 Privilege . . . . . . . . . . . . . . . . . . 18 Setting Paths . . . . . . . . . . . . . . . . 18 BBS Path . . . . . . . . . . . . . . . . 18 Help Path . . . . . . . . . . . . . . . 19 Message Path . . . . . . . . . . . . . 19 File Path . . . . . . . . . . . . . . . 19 Titles . . . . . . . . . . . . . . . . . . . 19 Area Types . . . . . . . . . . . . . . . . . . . 20 Local . . . . . . . . . . . . . . . . . . . 20 Matrix . . . . . . . . . . . . . . . . . . . 20 EchoMail . . . . . . . . . . . . . . . . . . 20 Area Aspects . . . . . . . . . . . . . . . . . . . 21 Privilege Levels . . . . . . . . . . . . . . 21 Public-Only . . . . . . . . . . . . . . . . . 21 Private-Only . . . . . . . . . . . . . . . . 21 Public-or-Private . . . . . . . . . . . . . . 21 Read-Only . . . . . . . . . . . . . . . . . . 21 Anonymous-OK . . . . . . . . . . . . . . . . 22 Special Considerations for Matrix Messages . . . . . . 22 NetInfo . . . . . . . . . . . . . . . . . . . . . 22 OPUSnode . . . . . . . . . . . . . . . . . . . . . 22 Cost Accounting . . . . . . . . . . . . . . . . . 22 Handling Crashmail . . . . . . . . . . . . . . . . 23 Refuse Crashmail . . . . . . . . . . . . . . 23 After Crashmail Exit . . . . . . . . . . . . 23 IFNA<tm> Kludge . . . . . . . . . . . . . . . 23 Extract ARCmail . . . . . . . . . . . . . . . 24 After ARCmail Exit . . . . . . . . . . . . . 24 Default Settings . . . . . . . . . . . . . . . . . 24 MATRIX Assume vs. MATRIX Ask . . . . . . . . 24 Kill/Sent . . . . . . . . . . . . . . . 25 File Attach . . . . . . . . . . . . . . 25 WARNING!!! . . . . . . . . . . . . . . . 25 Crashmail . . . . . . . . . . . . . . . 25 File Request . . . . . . . . . . . . . . 25 Update Request . . . . . . . . . . . . . 26 Return Receipts . . . . . . . . . . . . 26 Audit Trail . . . . . . . . . . . . . . 26 Special Considerations for EchoMail . . . . . . . . . . 26 Configuration Note . . . . . . . . . . . . . . . . 26 Areas.Bbs . . . . . . . . . . . . . . . . . . . . 26 Origin Line . . . . . . . . . . . . . . . . . . . 27 Automatic Toss . . . . . . . . . . . . . . . . . . 27 Seenby Displays . . . . . . . . . . . . . . . . . 27 Processing Outbound EchoMail . . . . . . . . . . . 27 OPUS Sysop Manual - Page ii Enhanced Message Area Commands . . . . . . . . . . . . 28 The Hurl Command . . . . . . . . . . . . . . . . . 28 The Forward Command . . . . . . . . . . . . . . . 28 Forward With Bombing Run . . . . . . . . . . . . . 28 The Zone Command . . . . . . . . . . . . . . . . . 29 Special Message Areas . . . . . . . . . . . . . . . . . 30 Hidden Areas . . . . . . . . . . . . . . . . . . . 30 Barricaded Areas . . . . . . . . . . . . . . . . . 30 Hints, Tricks, and Sleight of Hand . . . . . . . . . . 32 Directory Sorts . . . . . . . . . . . . . . . . . 32 Renumbering Message Areas . . . . . . . . . . . . 32 Disk Optimizing . . . . . . . . . . . . . . . . . 33 THE FILE SECTION What is a File Section? . . . . . . . . . . . . . . . . 35 Configuring a File Area . . . . . . . . . . . . . . . . 35 Upload Path . . . . . . . . . . . . . . . . . . . 35 Download Path . . . . . . . . . . . . . . . . . . 35 Titles . . . . . . . . . . . . . . . . . . . . . . 35 Files.Bbs . . . . . . . . . . . . . . . . . . . . . . . 35 Comments . . . . . . . . . . . . . . . . . . . . . 36 End-of-List Character . . . . . . . . . . . . . . 36 Wildcards . . . . . . . . . . . . . . . . . . . . 36 Handling Dates . . . . . . . . . . . . . . . . . . 36 Quirks, Peculiarities, and Caveats . . . . . . . . . . 37 External File Transfer Programs . . . . . . . . . . . . 37 Sliding Window Kermit . . . . . . . . . . . . . . 38 Windowed Xmodem . . . . . . . . . . . . . . . . . 38 OPUS SYSOP SUPPORT Installing OPUS Software . . . . . . . . . . . . . . . 39 The Control File . . . . . . . . . . . . . . . . . . . 39 The Control File Compiler . . . . . . . . . . . . . . . 39 Command Line Options . . . . . . . . . . . . . . . . . 39 Parameter File . . . . . . . . . . . . . . . . . . 40 Baud Rate . . . . . . . . . . . . . . . . . . . . 40 Time . . . . . . . . . . . . . . . . . . . . . . . 40 Port . . . . . . . . . . . . . . . . . . . . . . . 40 Unpack Mail . . . . . . . . . . . . . . . . . . . 40 The Sysop Menu ("!") . . . . . . . . . . . . . . . . . 40 A)rea Maintenance . . . . . . . . . . . . . . . . 41 D)elete Messages . . . . . . . . . . . . . . . . . 41 M)atrix Setup . . . . . . . . . . . . . . . . . . 41 E)vent Manager . . . . . . . . . . . . . . . . . . 42 O)utside Command . . . . . . . . . . . . . . . . . 42 Events . . . . . . . . . . . . . . . . . . . . . . . . 43 Embedded Commands . . . . . . . . . . . . . . . . . . . 43 User Access Levels . . . . . . . . . . . . . . . . . . 43 Sysop's Keyboard . . . . . . . . . . . . . . . . . . . 43 OPUS Sysop Manual - Page iii APPENDICES OPUS Program and Support File List . . . . . . . . . . 44 Embedded Commands . . . . . . . . . . . . . . . . . . . 46 For More information on OPUS . . . . . . . . . . . . . 54 OPUS Sysop Manual - Page iv INTRODUCTION What's an "OPUS?" OPUS is a computer-based conversation system (CBCS) that started with a conversation containing lines such as: "Gee, wouldn't it be nice if..." That was in December of 1985, and the current program reflects much in the way of enhancements to existing <tm> bulletin board systems. OPUS incorporates extensive messaging and conferencing capabilities along with a sophisticated software exchange system to create a fully interactive, user-friendly, bulletin board system. You'll find that OPUS is compatible with MOST of the support file structures used by FIDO<tm> version 11w. OPUS is also capable of receiving incoming Matrix traffic. This is compatible with FIDOnet<tm> network protocols, including SEAlink<tm>, a fast, full-duplex transfer protocol. About This Document This manual is supplied for reference to the sysop. It assumes you have already installed OPUS, and it is running properly. You will find many of the "bells and whistles" OPUS has described here, although you won't find out how to install it, or how to generate outgoing calls. These things are best discussed in a separate document. You should have received an installation program that will setup a basic OPUS. It pretty well covers all the dynamics of creating paths, and putting files in the right place. If you are a new sysop, you probably will want to run with the basic OPUS for a few weeks until you get comfortable with the OPUS method of operation. Once you understand which files do what, you should be ready to custom tailor OPUS for your interests and desires. When you initially install OPUS, you should keep it simple. Let OPUS do the work. It knows what it needs and where, and you can run into very perplexing problems if don't put things where they belong. You can always modify the system at a later date without reinstalling the software. There is also a file called 'OPUSER.DOC'. This is the user's guide to OPUS. It tells you what OPUS looks like from a user's point of view. This will aid you greatly in determining what features are available from what menus. OPUS Sysop Manual - Page 1 What does OPUS really mean? The word "opus" is Latin and means "project". Most folks think that OPUS is an alcoholic penguin from the comic strips. To tell you the truth, the guy who designed most of the OPUS CBCS hadn't read the comics in years; he had no idea why ANSI drawings of a rather perplexed bird started appearing on OPUS opening screens. We mention this for two reasons: First, it underscores the philosophy behind OPUS. OPUS is free, with no personal profit involved. We make no attempt to control OPUS' use or to alter what you think about the software, the matrix, or the state of the union. If you think OPUS is a penguin, we think that's just fine. OPUS is a tool for hobbyists, and should always be used for fun, not profit, or gain. Second, if you mention "foul" to any of us, we'll probably think you mean a bug in the program, not a pitiable bird in a tux. It may be a bird to you -- and that's okay. We know one thing for sure, in most cases, it's faster than a speeding bullet! The Rules for Using OPUS You have only two obligations if you want to use the OPUS system: 1. Be friendly about it. Don't start hollerin' at other OPUS Sysops or at its creators or one of our Help Nodes. OPUS is user-friendly software. You have to be friendly to use it. 2. Don't use OPUS to break laws. The Rules on Transferring OPUS Software You are specifically forbidden, under the terms of your limited license, to make money from the transfer of OPUS software. OPUS software must always be free. If your board charges a fee to users, then you may NOT keep OPUS software on-line for download. You can run OPUS, but you cannot distribute it because you charge money. You cannot "bundle" OPUS software with any other product when there is a fee for that product. OPUS Sysop Manual - Page 2 User groups and other non-profit organizations can distribute OPUS software on such things as "Disk of the Month", as long as there is no charge over-and-above the actual cost of the distribution diskette. If you paid money for your copy of OPUS, please contact one of the OPUSinfo systems. We want to know about it. List of Things Borrowed, not Blue We'd like to thank Ward Christiansen, who thought up the whole idea of bulletin boards and without who we would not electronic communications today. We also would like to thank Chuck Forsberg, who has done more for file transfer protocol improvements than any other single person. A special thanks to the folks at Columbia University, for their fine specification of sliding window Super-Kermit, and Jan A. van der Eyk, for his implementation of the protocol in CKERMIT. The current structure of OPUS owes a debt of gratitude to Tom Jennings, whose FIDO<tm> software and FIDONet<tm> network protocol provided much ancestral inspiration. CRC Routines. These were pillaged from a bulletin board. We found no name on the routines, but we need to say thanks anyway. Widgets, such as the ability to display the contents of an archive while online, were suggested by one of many sysops, without whom there there'd be no need for you to read this. System Enhancements Associates designed ARChive files, the SEALink file transfer protocol, and ARCMail. Bob Hartman created the communications driver OPUS!Comm, and did a great deal of the file transfer code. Jeff Rush designed EchoMail. Legal Stuff The SEALink file transfer protocol is copyrighted by System Enhancements Associates, who decided not to charge for its use if proper credit was given. We're giving that credit now, and there is a brief copyright notice on the protocol menu. OPUS!Comm is copyrighted by Sparks Software, and is licensed for use on this project. OPUS Sysop Manual - Page 3 Version Numbers Copies of OPUS always have at least numbers: 1.00 A major revision number change (such as from a 1.00 to a 2.00) is a serious change, and normally involves some structure incompatibility between the old and new versions. A conversion utility will be provided if possible. This would be something like changing the user file format from a FIDO<tm> compatible file to something a little more flexible and more suited to OPUS' abilities. On the other hand, a change from 1.00 to 1.10, isn't quite as drastic. Usually this will reflect the addition of new features that don't involve any major configuration changes. An example would be adding an additional file transfer protocol, or enhanced search functions in the message section. Finally, a move from 1.00 to 1.01 would be a very minor change. Maybe changing the wording in a section of text or something. And now, back to the regular BBS... OPUS Sysop Manual - Page 4 OVERVIEW Equipment Hardware Currently, Opus runs on an IBM-Compatible computer, or a DEC Rainbow with at least 128k of memory free. This means that you should have at least 256k so that OPUS will have enough memory after DOS and the driver programs are loaded. The difference between the IBM and the DEC versions, is the OPUS!Comm driver used. As of this writing, these are the only two drivers available. However, the specs for OPUS!Comm are public, and anyone who cares to can write drivers for other MS-DOS machine. For details, contact Sparks Software. Also, OPUS REQUIRES a storage device larger than a floppy drive. Generally, this will be a hard drive, but can be cartridge media such as a Bournoulli Box just as easily. There are absolutely no plans to release a version that will run on floppies; the support files simply take too much room. Theoretically, OPUS will use any modem that uses the Hayes command set and supports DTR. It has been successfully tested with the USR Courier, and the Hayes family. If you use another modem type, OPUS should work, but is not guaranteed. If you get other brands of modems to work with OPUS, please contact one of the INFOnodes and let them know the brand name and what you had to do to get it to work. Software Several pieces of software are required to make an OPUS work. You must have DOS 2.1 or greater. OPUS will run under DOS 2.1, but some of the features will not work. DOS 2.0 and 1.1 are NOT supported. DOS 3.1 is recommended for a fully featured OPUS system. You will also need to install the ANSI device driver that comes with DOS (this is built into DEC's version of DOS) in order to use the graphics capabilities of OPUS. ANSI allows your computer to send escape codes to the remote computer to tell it things like colors and cursor positioning. You can install ANSI by copying the file ANSI.SYS to the root directory of the drive your computer boots off of and adding a line in Config.sys that reads: device=ANSI.SYS This will install the necessary driver to allow OPUS to use graphics. If you see a lot of numbers,semi-colons, and left square brackets when OPUS runs, you do not have ANSI installed. OPUS Sysop Manual - Page 5 CONFIG.SYS File While we're on the subject of Config.sys, we might need to say a few more things about it. Config.sys allows you to set some of the operating parameters of your computer at boot time. There are three main commands that directly affect OPUS' performance: 1. FILES=xx This statement tells DOS how many files a single process may have open at one time. If a program tries to use more files than DOS allows, it generally does real nasty things; like deleting the currently opened files to make room for new files. Not a pretty sight. OPUS requires a parameter greater than or equal to 20. DOS allocates 48 bytes for each file defined in Config.sys, So you can be pretty liberal in allocating these. If you are running some sort of multi-tasker, remember that your file handles are divided by the number of tasks you have running. That is, if you are running two programs, and you have files set to 20, each task will be allowed to open 10 files. This will not work with OPUS. You will need to increase the number of files defined. The maximum number of file handles you can allocate is 255, but this is VERY excessive. 2. BUFFERS=xx This tells DOS how much information to read in at a time when a transfer is made from the disk to memory. Each buffer takes 528 bytes, so you might need to watch this if you are running in a limited amount of space. Generally speaking, if you specify too few buffers at boot time, you will slow the system down. If you specify too many buffers, you will slow the system down, so you really need to experiment with this one. We've found that a setting from 40 to 60 is about right on most systems. The largest number of buffers that can be allocated is 99. 3. COUNTRY=xxx This parameter specifies how the keyboard is mapped, the currency symbol, the decimal separator, and most importantly, the date and time formats. WARNING!!! OPUS WILL DO NASTY THINGS IF THE DATE FORMAT IS NOT AMERICAN!!! OPUS Sysop Manual - Page 6 You can still load an optional keyboard driver, but you cannot specify a country code other than 001. If you are experiencing dates showing up as garbage, you have your machine installed for the wrong country, even if you live there. 4. DEVICE=ANSI.SYS You must include this statement in any Config.sys file that will be used when an OPUS CBCS system is used. There are many enhanced ANSI drivers available, and some of them might even work. However, ANSI.SYS is the only currently supported driver. If you need help in setting up a Config.sys file, refer to the configuration section of your DOS manual. Actually, there is a very good description in the DOS 3.x manual and should more than answer any questions. AUTOEXEC.BAT OPUS also requires a couple of things installed in the Autoexec.bat file on your system. This is usually the best place to install one-time options and resident programs. Generally speaking, bulletin boards do NOT get along well with memory resident software such as dPath or Ready! Anything that installs its own keyboard routines will often cause conflicts with the routines for the bulletin board. You can try to use whatever programs you want with OPUS, but there is no guarantee that they will work. If you are experiencing strange problems with OPUS, uninstall any memory resident programs, and see if the problem stops. OPUS!Comm The low level communications routines that OPUS uses are contained in the OPUS!Comm program. This is a memory resident assembly language program that was specially designed for OPUS. It supplies all the routines for transferring information from OPUS to the modem. Because it is memory resident, it should only be run once, and is well suited to being installed in the autoexec file. Simply call OPUS!Comm from the autoexec file, and forget about it. If you are running other memory resident programs, you may experience some difficulty with OPUS!Comm. You can try installing OPUS!Comm last and that may solve the problem, but it is NOT guaranteed. Also, OPUS!Comm is a superset of the communications driver used by SEADog<tm>, which is an extension of the routines OPUS Sysop Manual - Page 7 used in FIDO<tm>. As a result, SEADog<tm> will recognize the OPUS!Comm driver and use it instead of its own routines. This will save you a few bytes of memory if you run SEADog<tm>. Set TZ= Internally, OPUS always works in Greenwich Mean Time. You rarely are exposed to this. OPUS tries to adjust to your time zone using a DOS environment variable called TZ. This is a standard practice for programs written in Lattice or MicroSoft C and you may already have this set correctly if you are a C programmer. If not, you will need to calculate the difference in time between your time zone and Greenwich Mean Time. This is not really that difficult and you can set it once and forget about it. We have some examples for the US, but you're on your own if you are overseas. The format for the variable is xxxyyy where xxx is the three letter designation for your time zone (I.E. EST for Eastern Standard Time), and yyy is a two digit signed number signifying the difference from Greenwich Mean Time to your time zone. Countries west of Greenwich will have a positive number, and those to the east will have a negative number. The sign is required in the definition. Here are the examples for the United States: Eastern For standard time.......... SET TZ=EST+05 For daylight time.......... SET TZ=EDT+04 Central For standard time.......... SET TZ=EST+05 For daylight time.......... SET TZ=EDT+04 Mountain For standard time.......... SET TZ=EST+05 For daylight time.......... SET TZ=EDT+04 Pacific For standard time.......... SET TZ=EST+05 For daylight time.......... SET TZ=EDT+04 OPUS defaults to Central Standard Time which is CST+06. If you are in the central time zone of the U.S., you don't have to set this, although it is still a good idea. OPUS Sysop Manual - Page 8 Functional Overview OPUS-CBCS is a conversational tool that supports several different types of information transfer. A few notes about nomenclature might be in order here. The Matrix The Matrix is the OPUS word for network. This was chosen instead of network due to the ambiguity associated with the word network in a FIDONet<tm> sense of the word. It is the Matrix which gives OPUS its edge over other <tm> bulletin board systems. The Matrix is defined as being a group of bulletin boards to which calls can be made to transfer information. OPUS itself, as of this writing, cannot place outgoing Matrix calls, although it is able to receive incoming mail from FIDO<tm> and SEADog<tm> systems at any time. You may use FIDO<tm> v11w or SEADog<tm> 3.82 or compatible mail programs in order to place outgoing calls from an OPUS system. OPUS incorporates provisions to use either of these packages for originating mail. As of this writing, OPUS is compatible with SEADog<tm> 4.0 (Yet to be released), but no guarantees can be made about FIDO<tm> v12, because the author has no information on interfacing to it. Messages Messages can basically be of three different types, or scopes. These are defined as local, network, and broadcast. Depending on the scope, a message will behave differently on an OPUS based system. Local Messages Local messages are the simplest form of message available. Almost all BBS systems have this type of messaging system. Local messages are available to a predefined group of users, but only upon the BBS that they were entered. They will not be marked to be sent to another BBS system. Matrix Messages Matrix messages are marked for transmission to a remote system or group of systems. OPUS cannot directly send the message, but the message format is compatible with existing <tm> network mailers, and fully supports the SEADog<tm> network extensions. This type of message is good for sending a note to a user or sysop in a different area. These types of messages can be used to OPUS Sysop Manual - Page 9 send files and request files, both on a scheduled basis or as immediate priority. The latter requires the use of a SEADog<tm> mailer. Broadcast Messages Broadcast messages are fully compatible with EchoMail. EchoMail, by Jeff Rush, it is a means of maintaining the same message base on multiple bulletin boards. This allows conferencing on an international level if you choose to do so. Remember, any Matrix associated, or broadcast message still requires that you make arrangements to transfer mail via an external mailer. Also, phone calls placed for mail transfers cost the same as regular calls. You need to be aware that anything involving Matrix transactions will cost you money to run. File Section File transfers can be of three different types. Uploads, Downloads, and Matrix file transfers are all supported in OPUS. These protocols allow you to share software with your users and other bulletin board systems. Uploads Uploading is defined as a user sending a file to the BBS system. This allows users to share programs that they have written or collected with other users of the bulletin board. Several transfer protocols are supported in OPUS. These include Xmodem, Ymodem, Telink, SEALink<tm>, Windowed Xmodem, and Sliding Window Kermit. These will be described more thoroughly in the file transfer section. Downloads Downloading is defined as a bulletin board system sending a file to a user. This allows a single point to serve as a 'holding tank' for software that can be freely shared among users. The same transfer protocols are available for download as for upload. Matrix Matrix transfers can either be uploads or downloads, but this works between two Matrix BBS systems. In other words, you can direct OPUS to mark a message as Matrix with a file attached, and the external mailer program will send that file to the specified system. OPUS will OPUS Sysop Manual - Page 10 accept incoming Matrix files any time the program is running. Operating Philosophy The operational philosophy of OPUS can be summed op in a very brief statement: KEEP IT SIMPLE! OPUS is very easy to use when you let the installation kit do its job. A sysop can lead a very satisfying life with the basic OPUS installation. It will still be a superior system, and will require a minimum of maintenance. There are thousands of custom features available; each OPUS board will probably look and act differently, but there is no guarantee that any of the customization methods will be easy or immediately apparent. It's best for the novice sysop to run a basic system and to gradually start customizing things as he/she gains experience with OPUS. That's what we suggest. The difficult functions are always available, but never required. If you want to tailor your system to look and act in just a certain way, you can at any time. However, remember the rewards you reap are proportional to the amount of work you put into the system, and that can run into man years if you choose for it too. Differences Between OPUS and FIDO<tm> OPUS is NOT a FIDO<tm> "clone"; it doesn't always try to mimic FIDO<tm> operations. The only compatibility between OPUS and FIDO<tm> involves the structure of the support files. For example, if you are currently running a FIDO<tm> system, then you can expect all of your "*.BBS" files to work with OPUS. That includes such text files as Dir.Bbs, Welcome1.Bbs, and so forth. It also includes the data files like User.Bbs, and Mail.Sys. There is no guarantee of compatibility beyond OPUS version 0.00. If file structures change, however, you can expect to see conversion programs to let you go back and forth between structures. File Structures This section describes some of the major differences in file structure between OPUS and FIDO<tm> v11w, and some of the enhancements in OPUS. The menu files have the same structure, however the contents of the menu files are very different. You must never attempt to operate OPUS using FIDO<tm> "*PRIV.BBS" files or vice OPUS Sysop Manual - Page 11 versa. All of the menu editing programs that are designed to work with FIDO<tm> "*PRIV.BBS" files will work with OPUS because the structures of the files are the same. The first character of each menu option does NOT have to remain the same in OPUS. OPUS is sensitive to the relative record position rather than any particular character. For example, if the third menu option is "M)essages", then OPUS doesn't care if you rename that to "N)otes". The third option would, in this example always get you to the message section regardless of what its name showed. Although OPUS understands the embedded signals for FIDO<tm> questionnaires, we recommend that you modify any questionnaire files to use OPUS embedded commands. This compatibility will probably be the first to go. OPUS defines two additional access levels: ASSTSYSOP - between Extra and Sysop HIDDEN - above Sysop (mainly to make unused menu items invisible) Extended Display File Capability ANSI graphics are supported as an option to the user. Each support file has two flavors: Text and Graphics. These are differentiated by extension in that text files have an extension of BBS, and graphic files use GBS. Through the use of an embedded command, you can have any support file branch to an external program. The sysop is responsible for insuring that the program directs its output through the comm port. This feature allows multiple "Outside" features to be supported. Questionnaire information can be collected from within any BBS/GBS file. This can be used to log the activity of any displayed section of your board. You can insert a person's name, display a quote, date and time displays, etc within any BBS/GBS file. Virtually anything OPUS knows about the user can be displayed at any point in the support files. Additional embedded commands allow you to make any BBS/GBS file a submenu. This is handy for things like multiple bulletins, interactive help systems, etc. For a complete list of embedded commands see Appendix D. OPUS Sysop Manual - Page 12 Extended File Transfer Protocols OPUS includes provisions for a variety of transfer protocols. These include Xmodem, Ymodem, WXmodem, Telink, SEALink<tm>, and Super Kermit. This allows virtually any computer system to transfer program files to and from the bulletin board. EchoMail Enhancements OPUS allows the sysop to determine whether EchoMail SEEN-BY lines are displayed to the user. Most people complain about the unsightliness of this part of EchoMail, and OPUS eliminates that problem. If you do not care about SEEN-BYs at all, OPUS allows you to disable their display. Extended FIDONet<tm> addressing display can be disabled. As more distinct addresses become available over the Matrix, there will be a need to embed more information within the body of a message. OPUS allows you to control who can and can't see this information. OPUS automatically inserts its own origin line if a message area is marked as broadcast. This allows other systems to know what package processed the mail. You can tell OPUS to automatically unARC and toss incoming EchoMail packets. In other words, when an incoming message has an ARCmail packet attached to it, you can tell OPUS to take care of placing it in the appropriate areas. You no longer have to declare an external event to extract ARCmail packets and toss EchoMail. OPUS does this for you. NOTE: These features require that you have all your message areas on the same physical drive. Unpredictable results will occur if this is not the case. Mail Interface OPUS has the ability to receive FIDONet<tm> compatible mail packets at any time. This means that Matrix transactions do not necessarily have to run at any given time. You send your mail to an OPUS at whatever time is convenient for you. OPUS messages are completely compatible with FIDONet<tm> and SEADog<tm> specifications. Even though it cannot place outgoing phone calls, OPUS allows any message entered on the system to be handled by a FIDONet<tm> compatible external mail program. OPUS Sysop Manual - Page 13 Extended Message Area Attributes A variety of message area attributes are supported. You can define exactly what type of messages will be placed in what area. Areas may be marked as being private only. This means that all messages entered in this area will be marked as private, and cannot be read by other users. Areas may be marked as public only. This will require the users to enter messages that can be read by any other user. OPUS supports anonymous messages. If an area is marked as being anonymous, OPUS will ask the user for the name that they want the message to be from. EchoMail message bases are recognized. The user will be told that the message will be broadcast, and OPUS automatically inserts the Origin line. Matrix messages are treated like FIDONet<tm> messages. The user is asked where the message is to be sent and to whom. Message areas can be marked as being Barricaded. A barricade is a file that defines legal passwords for that area. Passwords have a privilege associated with them, and using this feature you can allow people higher privileges within certain areas. Any of these attributes may be combined in any fashion. You can require all messages in your Matrix area to be private, or all EchoMail messages to be public. It is totally up to the sysop as to how message areas will behave. Message Area Commands OPUS adds four new commands to the message section, and one new command to the Matrix area menu. These allow you to do several things that FIDO<tm> does not allow. F)orward allows you to redirect a message to another user. This comes in handy when a user has entered a message to the wrong person. You can respecify who that message is sent to. F)orward has another variation called Forward as Bombing Run. This allows you to forward a message to a predefined list of people without having to reenter the message multiple times. H)url can be used to move a message from one area to another. You can move messages to the appropriate area if a user doesn't understand the system. This also works very OPUS Sysop Manual - Page 14 well for removing advertisements from EchoMail areas. NOTE: This requires all your message areas to be on the same physical drive. Unpredictable results will occur if you try to hurl a message to a different drive. =)Read non-Stop does just what it says. It will continuous display messages until the highest message is reached. The user may open a capture buffer, go into a message area, and essentially download an entire group of messages for reading offline. S)can will check for messages to the user in ALL message areas. There are several programs available that will create a file listing pending messages for a user. With this feature, the user can do this at the time he/she logs on. OPUS does not have a read message menu like FIDO<tm> does. All the commands for message areas are contained in one menu making message functions much easier to manage. In the matrix area, you have the ability to manage more than one list of Matrix addresses. FIDONet<tm> is in the process of implementing this by adding an additional level of network called Zone. This is the highest group and FIDONet<tm> defines these by country. OPUS uses a different approach. When you choose Z)one from the Matrix area in OPUS, you are really deciding on which nodelist OPUS will use. You can have as many zones as you choose. They can be grouped by country, continent, or however you want. In OPUS, the message editor commands are contained in a menu file. It works like any other "*PRIV.BBS" file and allows the system operator to set access levels for the various commands. The LORE (line-oriented editor) has an additional command: H)andling. It lets you manually change the attributes of a message. Current attributes consist of Private, Kill/Sent, File-Attach, Crash, File-Request, Return-Receipt Request, Update-Request, and Audit-Request. Some of these attributes are for use with external mail programs, and have no real use when sending mail to another OPUS system. File Area Commands Two new file area commands are added. H)url and O)rphan. H)url works for files just like it does for messages. O)rphan allows you to place entries in the file list for files that are in the directory, but not in the file list. OPUS Sysop Manual - Page 15 Miscellaneous Commands The user is not required to hit the return key when he/she logs on to establish a baud rate as he/she does in FIDO<tm>. OPUS does this automatically. ARC and LBR file contents can be displayed. The user can see what files are contained in an ARChive without downloading it. OPUS checks to see that a user exists on the system when a user addresses a private message to him. This insures that every message is receivable. This function is disabled in Matrix and EchoMail areas because these areas imply that the person the message is addressed to is not a user of the local board. All of the Sysop commands are menu driven in OPUS. This makes board maintenance much easier. The Sysop can either raise or lower a user's time and or access privilege from the local console. OPUS Sysop Manual - Page 16 THE MESSAGE SECTION What is a Message Section? Messages allow users to record notes to each other while they are online. This allows questions to be answered and conversations to be held between different users and the sysop. Opus implements this in a variety of forms. Messages can be local to the board or broadcast in a general conversation, and can either be public or private. These messages are grouped by category, with a separate subdirectory for each topic on your hard disk. You can have your messages grouped however you want them. The directory structure allows you to manage messages in an orderly fashion. You can define many things about message areas including who can see them, who can enter them, whether they are 'broadcast' or not, and whether they can be deleted. Setting up a Message Section System Files Each category, or area is referred to by its own number and has its own separate configuration file that allows the sysop to define the manner in which it will be used. These files are named as 'SYSTEM??.BBS', where "??" stands for the area number. Valid system area numbers are 1 thru 99. Each area is a separate subdirectory, and has unique characteristics. These include location, description, support, and privilege. Creating a System File Select "!" at the main menu to access the Sysop menu. From this menu you should choose A)rea maintenance. This menu always defaults to the main system menu, or area 0. This is the primary configuration for OPUS. It defines where the main help files are located, and where messages left at logoff go. Generally, you will not use the other options for the primary area, and you will set its access to Sysop. To create a new message area, select A)nother area from this menu. Pick a number that is one higher than your highest system file. If you have used the installation kit, you should pick three. OPUS will tell you that there is not an area three, and will ask you if you want to create one. Select yes, and you will see the area configuration menu. The following is a description of each of the items of the area configuration menu. You can set these options as you please, OPUS does not restrict area configuration in any way. OPUS Sysop Manual - Page 17 Privilege This option allows you to set the minimum privilege required for this area to be available to the user. Using this feature allows you to restrict usage of a message base to the people you have authorized. There are currently eight access levels: TWIT DISGRACE NORMAL PRIVIL EXTRA ASST. SYSOP SYSOP HIDDEN This allows you to set general access restrictions for a message base. You could have a general message base assigned a privilege of normal, and a private area devoted to your close friends defined as privil, and be assured that the private conversation would remain that way. See the Access Level description in the Sysop section later in this manual for more details on privileges. Setting Paths Most of the rest of the configuration section involves setting the DOS pathnames to the various support files. We do not intend to provide a tutorial on DOS. You should know enough about that already. We will give you a little background about the way OPUS treats pathnames. First, OPUS requires all paths to be fully qualified. That is, you must specify drive and subdirectory in each of the following items. If you don't, OPUS will tell you about it, and you will have to reenter the path. This is done to insure that all the information is absolutely where OPUS can find it. This also holds true in the control file though the compiler will not be so forgiving. More on that later on. Second, OPUS requires all paths to end in a trailing "\". Just to keep you on your toes, OPUS automatically puts this in for you in the system file configuration, but does NOT in the control file. When you are dealing with OPUS in an interactive mode, I.E. from the "!" menu, you do not have to enter trailing backslashes. All paths specified in the control file must have them. Got it??? BBS Path The BBS is the path to the privilege files to use for this area. Privilege files allow you to define which menu OPUS Sysop Manual - Page 18 commands are available to the user. Even though a user has a high enough privilege to access an area, he/she will not see the menu options that are set to a higher access level than his. Setting the privil files is discussed later under sysop commands. *** For Advanced Users*** You can have several sets of priv files contained in different subdirectories. This allows you to set two areas to access the same message base with different privileges. This allows you to give several people extended privileges within certain areas, by accessing different area numbers. Think about it. Help Path This allows you to specify the path to the help files for this area. These files are displayed when the help key (?) is pressed at the menu for this area. *** For Advanced Users*** Theoretically, you can display different help files for each area, but this is not generally used. Message Path This is the DOS path to the actual messages. This can be any valid DOS directory, and will be the storage place for the messages. When you initially set this path, OPUS will report that it cannot find a file called "DIR.BBS" and ask you if you want to create one. If you answer no to this question, you cannot use the T)itles option described below, and you are on your own to create this file. File Path This is the corresponding file area. See the file section for a description. Titles Each side of the area has a title that the user sees. This is the topic or category, and is maintained in the file 'DIR.BBS' in the appropriate subdirectory. OPUS allows you to modify the contents of this file from the area maintenance menu. It generally consists of a one line description of the contents of the area. This description OPUS Sysop Manual - Page 19 will be displayed immediately above the menu and when the user chooses A)reas unless the sysop has configured OPUS to use Msgareas.Bbs. (See the installation gude for further details). Area Types There are three basic area types for messages: Local, Matrix, and EchoMail. These determine the way a message is handled by Opus. Local Messages that are tagged local will only appear on the BBS, and will not be seen by users of another bulletin board service. These can be either private or public, and can have anonymous names, but will only be recorded on the computer the user is talking to when the message is entered. Matrix These messages are sent through the matrix, that is, they are generated in one city, and are sent to another single city. This is the equivalent of a letter. The user decides who it will be sent to, and where they live, and your board will generate a message that is compatible with an external mail program that can deliver the message. Naturally, you can define the users who can send mail to other users via the Matrix. This is discussed under the Mail section. EchoMail This is a means to share message bases between several boards. It allows you to create conferences that are shared between different parts of the country. EchoMail is not free. It still costs you the charge of sending a message to the Echo connection, but it generally allows conversations at a greatly reduced cost. Opus supports EchoMail internally for reception; it is up to the sysop to maintain a means of sending mail to another system. EchoMail uses several programs to link Opus to an external mail processor for managing EchoMail areas. See the related EchoMail documentation for details on how to participate in EchoMail. Opus provides direct support for incoming mail, and subsequent EchoMail processing. Therefore, the sysop is freed from the task of implementing it in batch files. (See the echomail special considerations section.) OPUS Sysop Manual - Page 20 Area Aspects The aspects you set for an area determine the way messages behave within that area. You can customize aspects to allow users to only read, only post public messages, or to allow them to post anonymous messages. Once again, OPUS leaves this entirely up to the sysop. Privilege Levels The privilege you assign an area determines the users that can access that area. This allows you to determine which users can read certain areas. Privs are downwards inclusive. This means that any user can access areas of his priv or lower. For example, you have set up four areas, two set to normal, one set to privil, and one set to extra. A user with normal privilege will be able to access the first two areas. A privileged user will be able to access the third area as well as the first two, and an extra user will be able to access all four areas. Privilege levels are the most general type of area aspects. Public-Only Message areas can be marked as being public-only. This will eliminate the question as to whether or not a message should be marked private. All messages entering in a public-only area may be read by any user. Private-Only You can mark a message area as being private only also. This will automatically tag every message as being private to the recipient. This is the inverse of the above, and will also eliminate the "Private?(Y/N)" question. The difference is that with this attribute, all messages will be private, while those areas marked with the previous attribute will contain nothing but public messages. Public-or-Private This is the default message area aspect. The user will be asked whether messages should be marked private, but public and private messages can be mixed within the area. Read-Only This attribute sets a message area to be non-postable. Users can read messages as much as they want, but they cannot enter messages. This is useful for general release notes, mini-bulletins, etc. OPUS Sysop Manual - Page 21 Anonymous-OK OPUS allows the user to enter the name to be used in the from field if this attribute is set. Normally, the users name is used in messages. You can use this to allow users to enter a pseudonym instead of their name when they enter a message. This is used mostly in EchoMail areas where many users discuss things. Special Considerations for Matrix Messages Although any of the above settings can be used in a Matrix area, it is generally not a good idea to change this area to allow anything other than normal messages. When OPUS creates a new system file, it defaults to being public and private messages, with no additional attributes. All that is necessary here is to add the Matrix attribute to the list, and you are ready to go. The other options that are configurable in a Matrix area are set within the control file. NetInfo The first option in setting a Matrix area is the NetInfo path. This tells OPUS where to find the FIDONet<tm> compatible nodelist. The syntax for the statement is: Path NetInfo d:\(path)\ where d: is a logical drive on your system and (path) is the subdirectory where you intend to keep the nodelist. OPUS itself cannot maintain this nodelist. To keep this list up to date you must use a utility such as OPUSnode, or Xlatlist. OPUSnode is included in the distribution kit and you should refer to the documentation with it for more information on maintaining nodelists. OPUSnode OPUSnode is an external nodelist compiler that allows you to create nodelists that are compatible with FIDO<tm>, SEADog<tm>, and OPUS. Without a nodelist, you cannot send Matrix messages with any of the external mailer programs. See the OPUSnode documentation for details on usage and syntax. Cost Accounting Because sending Matrix messages to a remote system can involve making long distance phone calls, OPUS maintains accounting information in the user file just like FIDO<tm>. If a user does not have enough credit to place an outgoing call, he/she cannot send any Matrix messages. You can use any of the external user file utilities that are compatible with FIDO<tm> v11w user file structures to set a users OPUS Sysop Manual - Page 22 credit. We recommend using REMSYS20, by Bernie Lawrence. It understands all of the extended OPUS attributes and can be run either from the local console, or through the modem. You can set a multitude of options about the Matrix area. These are all contained in the control file. The best documentation for the control file is the sample file contained in the installation kit. It was written by the author and is the definitive source for setting the control file options. This section only covers the options that relate to the Matrix area. Handling Crashmail A large portion of the Matrix configuration involves specifying how OPUS handles incoming mail. This section describes each of those options. Refuse Crashmail You can keep OPUS from accepting incoming mail. This is useful if you are not a member of the Matrix. If you do not belong to any Matrix group, you should include this in your control file: MATRIX Refuse Crashmail After Crashmail Exit After OPUS receives mail, you can exit the program with a DOS ERRORLEVEL set. This is for those who need to do special message/file processing after an incoming packet. The most obvious use is EchoMail's Scan. This is accomplished by including this line in the control file: MATRIX After Crashmail Exit xx where 'xx' is the DOS ERRORLEVEL you wish to exit OPUS with. The sysop is responsible for trapping this errorlevel and taking the appropriate action in the batch file. IFNA<tm> Kludge The International FIDO<tm> Association has devised a means for systems using their amateur e-mail network to pass extended control information with other programs. This is mostly extended addressing information for international mail and auditing information that tracks the processing of mail. You can set the privilege level of users that can see this extended information. Setting this priv to HIDDEN will prevent OPUS from displaying this information at all. The syntax for this statement is: MATRIX Kludge <priv> where <priv> is any valid privilege level (See Privilege Levels above). OPUS Sysop Manual - Page 23 Extract ARCmail ARCmail is an external mail packeting program created by System Enhancement Associates. It is commonly used in the processing and transfer of EchoMail. When ARCmail is crashed to your board, you can tell OPUS to automatically extract the compressed packets. If you use this feature, the program ARCE.COM must be available on your DOS path. ARCE is not OPUS software, and it is not supplied with this system. To use the automatic extraction feature include this in your control file: MATRIX Extract ARCmail If you do not have enough memory to run ARCE, see the sample control file for an example of how to do this by exiting OPUS after an incoming mail packet. After ARCmail Exit This is a special variation of the "After Crashmail Exit" option. The statement for this is: MATRIX After ARCmail Exit xx where 'xx' is once again a DOS ERRORLEVEL. Default Settings You can also tell OPUS what defaults to use for a message entered in the Matrix area. This includes things like private, kill/sent, etc. This allows you to specify exactly what a user can and cannot do with a Matrix message. There are two groups of configuration options here: Assume and Ask. If the attributes are not either assumed or asked, they are ignored. The sysop can always override these default settings using the H)andling option. MATRIX Assume vs. MATRIX Ask Assumed attributes are automatically set for messages entered in the Matrix area. Some of them will only work if you are using SEADog<tm> for your external mailer. The user does not have to do anything to set assume attributes, OPUS takes care of it. On the other hand, setting Asked attributes will make OPUS ask the user if he/she wants to set this attribute when the message is entered. Some attributes are more suited to Assume while others are better off being asked. For example, Kill/Sent is better off assumed as it generally confuses the user. The syntax for these commands is: MATRIX <verb> <attribute> where <verb> is either Assume or Ask, and <attribute> is one of the below. OPUS Sysop Manual - Page 24 Kill/Sent This attribute tells the external mailer program to delete the message after it is sent. A Matrix message is addressed to a remote bulletin board and is generally of no use once it has been successfully sent. Specifying this option will help keep your Matrix area tidy and decrease the amount of time your external mailer takes to process messages. File Attach Specifying this option will make OPUS ask the user for the name of a file to be sent to the remote system. WARNING!!! In this version of OPUS, file attaches can be from any valid path on your system. If you set file attach to ask, the user can send ANY file on your system to another system, where it can be publically downloaded. In future versions, this will be keyed off of a privilege level, and will incorporate some protections, but not yet. DO NOT SET FILE ATTACH TO ASK IN OPUS 0.00!!! If File Attach is not asked, the user cannot send a file to a remote system. The system operator, on the other hand, can get around this limitation by specifying the full path and name of the file to be sent as the subject, and using the H)andling command set the file attach bit. The rest of the message attributes will only work if you are using SEADog<tm> as your external mailer. SEADog<tm> and OPUS use a superset of the FIDO<tm> attribute specifications. FIDO<tm> will ignore any of the attributes listed below. This is a brief description of some of the extended attributes available with SEADog<tm>. See the SEADog<tm> manual for a more verbose description of these attributes. Crashmail Crashmail is defined as mail to be sent at any time of the day. OPUS can accept mail 24 hours a day if you so choose. It can also be used as the bulletin board under SEADog<tm>. If you implement the system this way, you can both send and receive mail all the time. File Request You can tell OPUS to set the attribute for the message to file request. This tells the system that receives the message to send the requested file back to your system. OPUS Sysop Manual - Page 25 Update Request An update request is similar to a file request except that the file will only be sent back if it is newer than the one that you already have on your system. Return Receipts If you specify a return receipt, the remote system will send you back a message telling you when it received the message, and whether or not the transmission was completely successful. This is very useful when the system you are calling is known to have bad phone lines, or you are making an overseas transmission. If your external mailer program uses routing, you may get nastygrams back from the host of the remote system. Some sysops do not like having to spend the money to deliver receipts. Audit Trail Audit Trails can give you very tedious details about the route a message or file took between your system and the remote system. As with return receipts, other sysops generally dislike having to make phone calls to give you this information. You can set any or all of the extended attributes if you are using FIDO<tm> as your mailer program. Some of the attributes will be passed on, mainly the request and receipt functions. This allows you to get some of the functionality of SEADog<tm> without having to purchase it! Special Considerations for EchoMail OPUS supports incoming EchoMail directly. That means that you can use OPUS instead of ARCmail and TossMail to process mail you receive. In most cases, OPUS processes incoming mail much, much faster than the external programs. Of course, this may not be true for your system as it depends greatly on the hardware you are using. Configuration Note All of OPUS' EchoMail support depends on you setting all your message areas up on the same logical drive. If you spread message bases between several drives, DO NOT attempt to use these features! Unpredictable results will occur. Areas.Bbs In order for OPUS to process your EchoMail, it has to have the EchoMail support file "Areas.Bbs" in the path specified OPUS Sysop Manual - Page 26 by NetInfo. If this file does not exist in the path specified by NetInfo, OPUS will not handle EchoMail directly. You can still use the external EchoMail programs; OPUS will just ignore any references to EchoMail support. Origin Line If OPUS finds your Areas.Bbs file, and a message area is marked as being an EchoMail area, OPUS will automatically insert an Origin line at the bottom of the message when a user saves a message. This origin line is fully compatible with EchoMail version 1.3?. The difference is that it will say "OPUS" on that line to differentiate OPUS from other EchoMail systems. Automatic Toss You can configure OPUS to automatically process incoming EchoMail. (See the Extract ARCmail section for that half of the process) OPUS can do all the functions of TossMail if you tell it to. To do so, you should specify the following line in the control file: MATRIX Toss EchoMail Once you've done this, OPUS will process incoming EchoMail with no further intervention required. You basically set it, and forget about it. Seenby Displays OPUS will suppress the display of EchoMail SEEN-BY lines if you tell it to. EchoMail uses these lines to determine which boards have already received a copy of a message. Sometimes the seenby line is longer than the message, though. Much like the IFNA<tm> kludge, this is primarily an internal function, and can confuse the user. If you set this option to HIDDEN, you will never have to see a seenby line again. You can set the privilege level that will see seenby lines with the following line in the control file: Echo Seenby <priv> where <priv> is any valid user privilege (See Privilege Levels above). Processing Outbound EchoMail At the time of this writing, OPUS does NOT support the processing of outbound EchoMail. This will be covered in later releases of OPUS. You can use whatever is convenient to you to achieve this externally. Generally, you will have to implement the following somewhere in an external event if you are using Jeff Rush's EchoMail and SEA's ARCmail programs: OPUS Sysop Manual - Page 27 SCANMAIL RUN ARCMAIL TO LIST AREAS.BBS (See the E)vents section under the sysops commands later in this document for details on how to do this with OPUS, or the manual for your external mailer program). Enhanced Message Area Commands As mentioned previously, OPUS provides three additional commands above and beyond those provided in FIDO<tm>. These commands are primarily for use by the sysop, but can be configured to be available to whatever level of user the sysop wants. They are standard menu entries and can be set to any privilege using the "!" (sysop) menu, or can be changed by any FIDO<tm> compatible menu editor. You can allow first time callers to have access to these commands, but it is not recommended. Generally, you will want these commands to be available to sysops and co-sysops exclusively. (See the P)riv section under the sysop commands later in this document for details on setting menu privileges) The Hurl Command This command allows you to move a message from one area to another. This is very similar to the M)ove command in the Mail interface for SEADog<tm>. It will copy a message from one area to another taking into account the number of messages in the destination directory. In other words, a message you hurl will end up being the highest message in the directory you move it to. You specify the destination directory by number. The Forward Command Forward allows you to change the recipient of a message. You can respecify the addressee of any message. If the message is in the Matrix area, OPUS will ask you for the network address again. Forward With Bombing Run This option is accessed by entering 'FB' at the menu prompt. This allows you to send the same message to a group of people. This group is specified by a text file. The name and location can be anything you wish, but you have to tell OPUS exactly what it is you want to do with this command. In other words, you probably should specify the full path and filename when using this feature. Also, OPUS is not particularly bright about the contents of the bombing run file. It has a very specific format, and if you do not follow that format EXACTLY, OPUS will try to OPUS Sysop Manual - Page 28 follow your instructions, and will make a very large mess of the entire affair. The format for the bombing run file is as follows: The beginning of each line starts with the address destination in the format of net number, followed by a slash, followed by the node number. After the address, you enter ONE and ONLY ONE space, followed by the name you want the message to be addressed to. The name field follows the format of the standard FIDONet<tm> nodelist. I.E. Underscores instead of spaces. You MUST use underscores instead of spaces. For example, a bombing run file would look like this: 100/10 Joe_Blow 103/12 Henry_Ford etc.... The Zone Command In the Matrix area, there is a special new command called Z)one. This allows you to specify the nodelist to be used for Matrix addressing. This defaults to the nodelist specified in the control file, but by using this option, you can specify which of several lists OPUS will use to find the Matrix address. If a user has enough credit, he/she can instruct your system to place a call to Hong Kong, or Australia, or some place equally expensive. This allows you to strip out all international addresses and only let continental mail be sent. Currently, FIDO<tm> has reached the limits of its nodelist handling capabilities, and is simply ignoring network addresses higher than the maximum it understands. OPUSnode allows you to break the nodelist into several discrete sections for use with your external mailer program. NOTE: Z)one is an internal command to OPUS. The sysop is responsible for insuring that the external mailer can understand the Matrix address that OPUS puts in the message. If this mailer is FIDO<tm>, you probably will not be able to do much with the capability to address multiple nodelists. If it is SEADog<tm>, then there is not much point in using this feature. OPUS supports the Zone designation in this manner primarily for future extensions to the OPUS mail interface. OPUS Sysop Manual - Page 29 Special Message Areas There are two additional types of message areas supported in OPUS; Hidden and Barricaded. This allows you to create areas that only certain users can access WITHOUT allowing them a higher privilege, and to allow extended privileges within a certain area. The variations on this idea are countless. This will provide many different security levels to be configured without any additional work for the sysop.This is a VERY advanced concept and should be explored by the novice sysop gradually. Hidden Areas During the develpment of OPUS, we came across a quirk that has proved very useful. No one really thought it out; it just happened. Since then, this has become one of the most popular aspects of running an OPUS system. You can define a system file that is more than one higher than the highest existing system file. I.E. you can have areas 1 thru 10 and 20. Area 20 will be an area that acts exactly like any other area, but it will not show up for the user in any list. Valid area numbers for Hidden areas are 1 thru 49. The "Hidden" areas are a low security means to keep the general public from accessing an area. The user must know that the area exists to get there, but if he/she randomly types the area number, there is nothing to keep him out of that area. You will find that as OPUS becomes more popular, users will try to access each and every area in an attempt to read areas they are not authorized to read. Its not that every user out there is a "black hacker magician"; they are naturally curious, and will explore any possible combination of commands they can think of. This is why OPUS provides Barricaded areas. Barricaded Areas Barricaded areas use a separate configuration file to define the password and privilege a user will have in that area. Even if a user randomly chooses the area number for a arricaded area, they will still have to know a password before being allowed entry to that area. Valid Barricaded area numbers are 50 thru 99. When you create a system file higher than 50, OPUS changes the BBS path to Barricade path. This is the fully qualified path designation for a file that contains the barricade information. You can specify the filename for this file in addition to the path; it is not hard-coded. As in the bombing run file, this file must follow a specific format: OPUS Sysop Manual - Page 30 Each line starts with a password. This can be any number of characters up to 255, but keep it reasonable. If you specify much more than 20 or 30 characters, your user may run out of time before he/she types in the password! After the password, follows one, and only one space. Any more or less and the user will not be able to access the area. The last word of the line is the privilege descriptor as described in previous sections. If OPUS decides that the format of this file is wrong, or that the user is not authorized to enter the area, his privilege will be lowered to the minimum. The only way to recover from this is to logoff and log back on. Once a user misstypes the password for a protected area, he/she will be reduced to TWIT and will not be able to recover without sysop intervention. The password file can contain as many entries as you like, and you can have multiple passwords for similar privileges. This is what an example control file would look like: abc twit password normal additional privil xyz twit newpassword extra oldpassword privil This file would allow users to enter either 'abc' or 'xyz' as a password to enter that area with a privilege of twit. A password of 'password' would alow them access at normal, and 'additional' and 'oldpassword' would get them privil. We think you get the idea. The sysop is responsible for informing users what passwords to use in what areas. OPUS will allow anyone who can enter the appropriate password access to that area. Barricades generally are used to allow friends and business associates extended privileges to certain areas. The privilege a user gets in a barricaded area is temporary and only works in that area. This allows you to map a password protected area to a normal area and designate a "moderator" for a message area. For instance, system file 3 points to a directory called 'C:\Msgs\Group' and so does area 51. Normal users can enter area 3 and do whatever users OPUS Sysop Manual - Page 31 normally do in message areas. You have a password file for area 51 that gives users who enter a password of 'moderator' the privilege of sysop. This allows your friend Joe to act as the sysop within area 3 if he/she enters area 51 and gives the appropriate password. Within the distribution kit you will find a file called TEST.DOC. This quizzes you on details of hidden and barricaded message areas. You should complete the quiz and mail it back to one of the info nodes. Ready??? Hints, Tricks, and Sleight of Hand One of the primary purposes in OPUS is to handle bulletin board tasks as quickly and efficiently as possible. Every aspect of OPUS was written with speed as the primary goal. You will find that it fulfills this goal on its own with the exception of a couple of areas. Directory Sorts OPUS tries very hard to find its configuration files as quickly as possible. Due to the nature of DOS, this can still take quite a bit of time unless you help OPUS from time to time. You will find that OPUS will run much quicker if you use some utility to sort your directories. Professor Norton's DIRSORT works very nicely. This has two advantages. First, by nature, it sorts all directory names to the top of the directory listing. This allows OPUS to fly through path finding operations. Second, directory sorting will force deleted file entries to the bottom of the list. You dodn't know DOS kept entries for deleted file??? Of course. That's why when you delete all but one file in a directory it takes half a lifetime to display a directory. OPUS can deal with unsorted directories just fine - you just sacrifice speed. There are many utilities that sort directories and they improve performance greatly. If you don't already have one, you should consider finding one. Renumbering Message Areas By nature, message areas are not necessarily contiguous. As a message base ages, messages are either killed by users, or deleted by date. As this occurs, "holes" are left in the message base structure. These holes slow down the time it takes OPUS takes to determine the highest message, and how quickly OPUS finds the next highest message for viewing. If you do not periodically renumber your message areas, eventually, OPUS will spend all its time skipping directory entries and will never get its work done. OPUS Sysop Manual - Page 32 Naturally, there are solutions that take care of this problem. One, RENUM by Bob Hartman, seems to work best with OPUS. It has several options only one of which we will discuss here. RENUM will go through a message base and insure that the highest message number actually reflects the highest number of message files. In other words, it will eliminate any gaps you may have in your message base by changing the higher message numbers to fill in the gaps. Your messages will still be in chronological order, it does not rearrange them, it just insures that if you have 100 messages available, they are numbered one thru one hundred. OPUS remembers the highest message a user has read. Due to the limitations placed on it by FIDO<tm> compatibility, OPUS can only maintain high message markers for ten areas in the user file. FIDO<tm> only maintains eight. However, OPUS knows that the sysop will mainly be reading messages from the local console, and uses a different means to record the highest message read for the sysop. This involves treating the marker in the fashion SEADog<tm> uses. Each time you read a message from the keyboard, a file called LASTREAD is updated in the message area you are reading. Because this information is maintained in the same directory that the messages are in, OPUS can maintain an infinite number of message pointers. If you use Bob Hartman's RENUM to maintain your message bases you need to specify '-S' as the first parameter of the command line to tell RENUM to maintain the LASTREAD files. While providing support to an unlimited number of areas, this feature is restricted to one user. If you use another renumbering program, you need to insure that it takes the LASTREAD files into account. Disk Optimizing Last, but not least, you need to run some sort of optimization on your disk drives periodically. Because of the way DOS manages directories, you will end up with an area that is mostly deleted files. This is especially true if you use EchoMail and ARCmail. By nature, these programs generate a whole bunch of messages and then delete them after moving the information to another directory. DOS still retains a directory entry for each deleted file. You will find that the more deleted file entries there are in a directory, the slower the programs that access that directory will work. This is especially true of EchoMail and ARCmail. The slow down is proportional, but not on a one to one basis. If you have half as many messages to process as you have directory entries, you should expect to spend four times the amount of time processing them. This is not quite so obvious with small message bases as it is with large ones, but the delay is still there. OPUS Sysop Manual - Page 33 We have found DOG (Disk OrGanizer) to be a very good solution to this problem. It has options to allow you to run it unattended in a batch file, and its Fast option seems to take care of the problem without wasting a lot of time. On an eight megahertz 286 based machine it generally takes two minutes if run daily. OPUS Sysop Manual - Page 34 THE FILE SECTION What is a File Section? The file section of OPUS allows the users to exchange programs and information contained in files that they create offline. File sections are treated much the same as message sections, and configuring them is so similar that we will only discuss the areas that directly affect the file areas. Configuring a File Area You configure the area of your hard drive that will contain a file section very similarly to the manner in which you configure a message section. Select the "!" command from the main menu, and pick A)rea maintenance. There are only three options here that affect file areas. Upload Path The DOS path you specify here is where files that are sent TO your system will be stored. You can set all your upload paths to the same subdirectory, or to separate subdirectories. The sysop is entirely on his own to manage these files once they are sent. Download Path This path specifies where OPUS will look for files that the user requests to be sent to him. You should divide your download areas up by type of program. I.E. use one area for utilities and another for games. You can have up to 99 individual file areas. Titles Each file area has a one line description which is contained in the file Dir.Bbs in the download path. OPUS allows you to change the contents of this file using the T)itles command. This description is displayed at the top of the menu when the user is in a file area. This description will also be displayed whenever the user chooses A)reas from the file section menu unless the sysop has configured OPUS to use FileArea.Bbs. (See the installation guide for more details). Files.Bbs The list of files in an area is contained in the file Files.Bbs in the area subdirectory. OPUS maintains this list for you for files that are sent to your system. The file is a standard text file, and can be created with any text editor that outputs pure ASCII files. The basic format of OPUS Sysop Manual - Page 35 the file is as follows: <filename> <description> with one filename listed per line. Multiple description lines are supported as long as the first character of each line in the description is a space. Comments Lines that begin with a dash ("-") are used for headers and important announcements in Files.Bbs. Whenever OPUS sees a dash as the first character of a line, it changes the screen color to white if the user has graphics enabled. For normal comments and multiple line file descriptions, use a space for the first character of the line. You can place comments anywhere in Files.Bbs. End-of-List Character The end-of-list character is the "@" sign. If OPUS sees this character as the first character of a line, it will not display anything in the file after that character. This is useful for allowing users to upload files into an area without allowing subsequent download of the file until it has been checked by the sysop. Wildcards OPUS allows wildcards to be included in Files.Bbs. When OPUS encounters a wildcard in the files listing, it will expand the file list to include any files that match the wildcard. If there is a description after the wildcard, it will follow the last file matching the wildcard that OPUS finds. This is very useful for maintaining lists of files that are sent to your system via mail. Because these files are not uploaded by a user, OPUS does NOT add a line to Files.Bbs signifying that the file is available. This feature allows you to make files that are sent to your system available for download without requiring any maintenance. Wildcard support is very limited and should be used with care by the sysop. Files listed with wildcards can only be downloaded by users that are privil and above, and commands like L)ocate will not find these files. This is a temporary limitation and will be changed in future versions. Handling Dates OPUS allows the sysop to handle dates in the file lists in several ways. The sample control file explains this in greater detail. Suffice to say, if you need Files.Bbs to contain a date after the filename, OPUS can be configured to do that for you. However, this will disable the display of OPUS Sysop Manual - Page 36 new files for the user. Normally, OPUS will display an asterisk by the file date if the file has been added to the system since the last time a user called. Hard-coding a date into Files.Bbs will disable this feature, but may allow some utilities like Shuffle and FFM to work with OPUS formatted Files.Bbs listings. If this is important to you, see the sample control file for information on how to place dates in Files.Bbs. Quirks, Peculiarities, and Caveats There are several aspects of file areas that need to be mentioned here. Several are useful for monitoring system usage, while others are merely offshoots of the design of OPUS. OPUS will never overwrite a file that exists in a file area. FIDO<tm> uses an attribute bit to allow files to be overwritten in the network mail area. OPUS allows you to configure that bit, but it will ignore it, and never overwrite a file. Instead, it will change the last character of the file extension to a sequential decimal number. In other words, if you have a file called "file.txt" in an area, and a user tries to upload a file with the same name, OPUS will name the first upload to "file.tx0". The second will be "file.tx1" and so on. After ten duplicate files have been uploaded, OPUS simply stops accepting that filename. The sysop is free to use any of the embedded commands within a files.bbs listing. You can record information about the user in a log if you want, or even place menu instructions in this file if you wish, although it serves no purpose. (See the Embedded Commands section below). Of primary importance here are the line privilege commands. and rest of file privilege codes. WARNING!!! Shuffle will suffer extreme delusions if you use it with embedded commands. Use the built in OPUS commands to manage files if you use these codes in your Files.Bbs listings. External File Transfer Programs OPUS supports several file transfer protocols in the form of external programs. In other words, you must have another program besides OPUS to allow users to make use of these commands. Currently, the author of OPUS is working with the authors of OPUS!Comm to make a generic external transfer program interface. Future versions of OPUS will allow you to specify any protocol for which you can provide the code for as long as it meets the specifications for the OPUS interface. OPUS Sysop Manual - Page 37 Sliding Window Kermit Super Kermit is supported in the file CKERMIT.EXE by Jan A. van der Eyk. You must tell OPUS where this file is in the control file. If present, users may use this fast, full- duplex protocol for both upload and download. Many thanks to Columbia University for developing this outstanding file transfer protocol. Windowed Xmodem This is implemented in the same fashion as Super Kermit. The required program is WXMODEM.COM. You must specify the location of this program in the control file in order for it to be accessed by users. (See the installation kit for details). Future versions of OPUS will include support for Chuck Forsberg's ZModem protocol. We simply ran out of time for this release. This protocol is running a close race with Super Kermit for the fastest file transfer routine available. OPUS Sysop Manual - Page 38 OPUS SYSOP SUPPORT Installing OPUS Software OPUS comes with an installation program that will do most of the work of installing the system for you. You should let these programs do their job BEFORE you go mucking about with the way OPUS works. Manual installation is NOT recommended at all. See the installation kit for further details. The Control File The primary emphasis in OPUS is speed. Everything possible has been done to make OPUS work as quickly and efficiently as possible. In order to increase the speed of loading the program, much of the configuration information is contained in a control file. This file deals with paths and privileges mainly. All of the options in the control file are documented, and you should refer to the sample control file for an explanation of each command. The Control File Compiler The compiler takes a text file that you build and turns it into memory-image information for OPUS to use. The program OPUS_CTL.EXE MUST be run each time you change your configuration options. If you do not run the compiler, OPUS will use your old control file. To compile an OPUS control file, issue the following command from the DOS prompt in your OPUS root directory: OPUS_CTL <control file name> OPUS_CTL will convert the control file to machine-readable code. This is done to decrease the work OPUS has to do at startup time. If a control file was not used, OPUS would have to do the work of OPUS_CTL each and every time it executed. The control file that you can change and is readable defaults to an extension of "CTL" for "Control". This is the file that you can manually change. The compiler creates a runtime image of this information and stores it in a file named the same as your control file, but with an extension of "PRM" for "Parameters". You can create as many different parameter files as you wish. The parameter file that OPUS uses is specified on the command line when OPUS is invoked. Command Line Options OPUS supports several items on the command line. This is OPUS Sysop Manual - Page 39 primarily for SEADog<tm> support. The following is a list of things you can specify on the command line: Parameter File The first item in the parameter list is the name of the control file that you wish OPUS to use. You do NOT specify an extension unless you have changed the extension from "PRM". Baud Rate As with FIDO<tm>, you can specify the baud rate of an incoming call for use with SEADog<tm>. The syntax is: -bxxxx where 'xxxx' is the baud rate of the caller. See the SEADog<tm> manual for details. Time You can tell OPUS how much time remains till the next SEADog<tm> event. Use this syntax: -txxx where 'xxx' is the number of minutes until the next SEADog<tm> event. Port Comm ports can be specified using this parameter: -px where x is the communications port. Valid parameters are 1 and 2. Unpack Mail If you invoke OPUS with a '-u' switch, it will attempt to unpack any received mail. If mail packets are found, OPUS will do whatever you have told it to do in the control file. The Sysop Menu ("!") OPUS allows most of the configuration that is not support file specific to be done online. All sysop commands are accessed via the "!" command on the main menu. The sysop menu supports all of the commands accessible using numeric commands in FIDO<tm>. The big difference is that all of the OPUS commands are menu driven, and you don't have to remember obscure syntax rules to use them. OPUS Sysop Manual - Page 40 A)rea Maintenance There is not much point in discussing this command further. It is fully covered in the above sections. It allows you to specify the paths and privileges for message and file areas. D)elete Messages This command allows you to delete messages by date or by whether they have been received or not. In other words, you can tell OPUS to delete all messages that have been sitting around for a while. This prevents your board from becoming "dated". Usually, you will use this to eliminate messages that are older than about a month or so. If a user is not interested enough to call your board at least once a month, he is not interested in conversing with other users on your board. Delete by date will unconditionally delete messages that are older than a time frame you specify. Delete Received will kill any messages that have already been received by the user. OPUS will ask if a message should be deleted at the time it is received, but users do not always say yes to this question. This command will eliminate any old received messages that might be lying about. Both of these features are included in the external program RENUM by Bob Hartman. The sysop can implement this program in a fashion that will automatically do the above functions on a daily basis. See the RENUM documentation for further details. M)atrix Setup This command is the equivalent of the FIDO<tm> "4" command. It allows you to set your Matrix address(es) and select the paths to your Matrix message area and Matrix file area. Addresses are determined by the administration of the amateur network you belong to. OPUS allows you to specify a primary and alternate net/node number. This command maintains the information contained in the file "Mail.Sys" and is fully compatible with FIDONet<tm>. See your external mailer program documentation for more information on addresses. The paths you set using this command coorespond to a system file's paths that you have marked as being a Matrix area. In other words, regardless of what you have set using the A)rea maintenance command, you must duplicate this information in this configuration file. This redundancy will probably go away in future versions of OPUS, but for now, you must specify your mail paths in two places. OPUS Sysop Manual - Page 41 Hint: Most sysops set this command once and forget about it. If, for some reason, you change the locations of your mail messages and files, it is very easy to forget to change this option. REMEMBER TO CHANGE YOUR MAIL PATHS IN BOTH A)REA MAINTENANCE AND M)ATRIX SETUP!!! E)vent Manager This option allows you to manage OPUS events. Events tell OPUS to do certain things at certain times. See the enclosed "REF_EVNT.DOC" file for further information. P)riv. Setup Using this option, the sysop can define the minimum privilege required to access a menu item. This item allows you to change the privilege for any item that appears on an OPUS menu with the exception of the file transfer protocol menu. You can use this command to configure what menu options are available to what users, including the sysop menu. Any menu item in OPUS can be assigned any of the available privilege levels between TWIT and HIDDEN. See the enclosed "REF_PRIV.DOC" file for a description of privilege levels. O)utside Command This command allows you to exit OPUS with an ERRORLEVEL specified in the control file. FIDO<tm> calls this the "Zero" command. You can use this to allow you to exit to DOS when you call your system from a remote location. This is a very powerful command, and should be used with GREAT caution. Author's Note OPUS has been developed over an extended period of time. This document has existed for a very brief time. As a result, this section is not quite as complete as it should be. I am relying very heavily on other support documents that were never really meant to be used for this purpose. It is 45 minutes until OPUS is released to the public, and this document is not complete yet. Within a couple of weeks, a more complete document will be made available. Until then, you will have to dig through the technical reference docs to find the rest of the information that should be in this document. OPUS Sysop Manual - Page 42 Events See "REF_EVNT.DOC" Embedded Commands See "REF_CTRL.DOC" User Access Levels See "REF_PRIV.DOC" Sysop's Keyboard See "REF_KBD.DOC" OPUS Sysop Manual - Page 43 APPENDICES OPUS Program and Support File List ----------------- Files used by Opus ------------- The following files are hard-coded in Opus, and cannot be renamed. CHGPRIV BBS - C)hange menu DIR BBS - Area header in each area. FILES BBS - File listing in each file area. EDITPRIV BBS - Message editor menu FILEPRIV BBS - File menu MAILPRIV BBS - Matrix menu MAINPRIV BBS - Main menu MSGPRIV BBS - Message menu SYSPRIV BBS - Sysop menu SYSTEM BBS - Main System file SYSTEM1 BBS - Message / File area 1 SYSTEM2 BBS - Message / File area 2 (etc......) LASTUSER BBS - User record of last user to go outside. SCHED BBS - Schedular record OPUSCHAT TXT - Chat buffer MAIL SYS - Net/Node number record OPUSGRAF EXE - Displays settings in Control file OPUS_CTL EXE - Control file compiler F1 BBS \ F2 BBS \ F3 BBS \ F4 BBS \ F5 BBS \ Function key display files. F6 BBS / These can be .GBS for graphics F7 BBS / F8 BBS / F9 BBS / F10 BBS / C HLP - C)hange help screen FILES HLP - File area help screen MAIL HLP - Matrix help screen MAIN HLP - Main menu help screen MSG HLP - Message area help screen OPUS EXE - Opus itself The following file CAN be changed in Opus, but should not be changed if you are running a Opus/Fido setup. ANSWER BBS - Q)uestionaire answer file USER BBS - User records BULLETIN BBS - System Bulletin WELCOME1 BBS - Initial welcome screen OPUS Sysop Manual - Page 44 WELCOME2 BBS - Second welcome screen EDTORIAL BBS - System Editorial NEWUSER1 BBS - Initial New user screen NEWUSER2 BBS - Second new user screen QNEWUSER BBS - Auto questionnaire for new users QUESTION BBS - Q)uestionaire file QUOTES BBS - System Quotes These files can be renamed with impunity. OPUS CTL - Opus Control File OPUS LOG - Sysop Log OPUS PRM - Opus Parameter file (compiled OPUS.CTL) EDITOR BBS - Help screen for the Editor INQUIRE BBS - help screen for the Inquire command LOCATE BBS - help screen for the Locate command BYEBYE BBS - Logoff screen CONTENTS BBS - help screen for the Contents command DAYLIMIT BBS - Shown to users that have no time left for the day. FILEAREA BBS - List of file areas. LEAVING BBS - Show to users before they go outside MSGAREA BBS - list of message areas RETURN BBS - Shown to users returning from Outside REP_EDIT BBS - Help for the REPLACE option on the Editor menu ROOKIE BBS - Welcome 2 screen for users with less than 7 calls. TIMEWARN BBS - Time limit warning TOOSLOW BBS - Shown to users that are calling at too slow a baud rate. WHY_ANSI BBS - help screen for the (ANSI y/n) question WHY_FB BBS - help screen for the logoff message prompt. WHY_HU BBS - Help for the G)oodbye command WHY_PVT BBS - help for the (Private y/n/) prompt on messages. XFERBAUD BBS - Screen for users that are too slow to up/download OPUS Sysop Manual - Page 45 Embedded Commands You can lead a full and meaningful life without using any of these control codes. In fact, misusing them can probably lead to a lot of grief. There is nothing here for the novice. If you are not intimately familiar with Opus and running communication systems, please don't continue. Most of the control codes assume you know what you are doing. Because the GBS/BBS files are prepared with a word processor or text editor (ie...not using any Opus software), there is no way for Opus to check your work. You should review any files you create using Opus's KEYBOARD MODE before trusting the file to an on-line situation. The Control-O commands (below) can be particularly lethal if you aren't careful. An overabundance of control codes in a BBS/GBS file can make a totally unmaintainable file. You can build these files using any text editor that's capable of inserting control codes into files, but I would consider such a method the "Assembly Language of BBS/GBS Files". A handy Opus sysop utility would be some sort of program (eg. WYSIWYG BBS/GBS editor) to make these control codes more readable to the sysop during development. At this writing, no such utility exists. [soapbox on] It's very possible to use these commands to turn a perfectly good system into one full of gimcracks (useless junk). An Opus sysop has an order of magnitude more power over his/her system than does a Fido<tm> v11 sysop. If you take that control, you must also share the responsibility. I think it's great to add a little spice to a system, but the average user doesn't call in order to see his/her screen wiggle. These commands are intended to give the experienced sysop lots of versatility. They are very easy to over-do! Also... remember that if you use the MsDOS graphics characters in a BBS/GBS file, you are going to make non-MsDOS screens look funny because they won't know how to display the characters. There is absolutely nothing "non-standard" in Opus itself. If you choose to add such features, you also need to be prepared to answer questions and/or complaints about them. [soapbox off] These control codes can be inserted into any .BBS or .GBS file. The only exception is DIR.BBS ... which must be a plain text file. OPUS Sysop Manual - Page 46 THE BASICS ------------------------------------------------- ^A ... "Press ENTER to continue: " ^B ... disable ^C/^K aborting ^C ... enable ^C/^K aborting ^D ... Mark that it's a good time for a "MORE?" ^E ... Turn auto-More ON (default) ^F ... COMBINATION COMMAND (see below) ^G ... Ring the caller's bell ^H ... Backspace ^I ... Tab ^J ... Line feed ^K ... Turn auto-More OFF ^L ... Clear screen ^M ... Carriage return ^N ... [ reserved ] ^O ... COMBINATION COMMAND (see below) ^P ... COMBINATION COMMAND (see below) ^Q ... Used for XON/XOFF. Never use this. ^R ... [ reserved ] ^S ... Used for XON/XOFF. Never use this. ^T ... [ reserved ] ^U ... [ reserved ] ^V ... [ reserved ] ^W ... [ reserved ] ^X ... [ reserved ] ^Y ... [ reserved ] ^Z ... MsDOS end of file marker. Never use this. DATA DISPLAY ----------------------------------------------- NOTE: Both command characters in this section are CONTROL characters. The `^' symbol means `control.' For example, `^F' represents CONTROL-F. ^F^A ... quote of the moment ^F^B ... user's name ^F^C ... user's city/state ^F^D ... current date ^F^E ... total number of calls user has made to system expressed as an ORDINAL number (eg. `1st', `2d', etc) ^F^F ... user's first name ^F^G ... dramatic one-second pause ^F^K ... total minutes on-line in the last 24-hours, including the time for the current call ^F^L ... length of the current call so far (in minutes) ^F^N ... control-niel (disconnect) ^F^O ... number of minutes remaining for this call ^F^P ... written-out date/time when the user has to be off the system. NOTE: This uses a built-in Lattice-C routine which appends the line with a <CR/LF>. You OPUS Sysop Manual - Page 47 should consider using ^F^P at the END of a line with no punctuation ... until Prof.Norton and I can get in and change a couple of things. ^F^Q ... number of calls to system to date (ORDINAL NUMBER) ^F^R ... NET downloads today (download minus upload) If uploads are greater than downloads, this number will be negative. ^F^T ... current time ^F^U ... on a questionnaire, all answers are required ^F^V ... on a questionnaire, all answers are optional ^F^W ... total user uploads ^F^X ... total user downloads ^F^Y ... upload:download ratio QUESTIONAIRES, SURVEYS, ORDER FORMS ------------------------ NOTE: The second character of the commands in this section is a REGULAR ("printable") character ... NOT a control character. HINT: Calm down a little, there are samples at the end of this file. ^OMd ... store the last `^OR' response to the answer file. (See `^OR' below). `d' is is a description of the item which is NOT displayed. The description is stored in the answer file. Also, see the examples at the end of this file for more information. ^ONd ... let the user type a line and store it in the user file. This roughly corresponds to the Fido<tm> "/" command in questionaires. `d' is for a description of the entry in the answer file. ^OOf ... open an answer file. `F' is a fully-qualified file name including path, node, and extemsion. ^OP ... post user information to the answer file OPUS Sysop Manual - Page 48 FLOW AND USER INTERACTION ---------------------------------- NOTE: The second character of the commands in this section is a REGULAR ("printable") character ... NOT a control character. "Remember-- no matter where you go, there you are." --Buckaroo Banzai ^OCp ... call MsDOS with the command "p". This is an embedded "O)utside" command. "P" is some command, possibly the name of a program or batch file. It is sent to MsDOS (via Command.Com) without modification. ^OFb ... "On exit". Declare the name of a GBS/BBS file to be transmitted if, for any reason, the current file is terminated. ^OQ ... quit the file immediately ^ORv ... read menu. `V' is a sequence of characters ... a list of the valid responses. Opus considers all of the characters between the `R' and the first character less than or equal to the space character to be part of the list. In other words, you terminate the list with a space, tab, end of line, or any other control char- acter. Refer to an "ASCII CHART" for help in finding what characters are "below" the space. Opus takes care of upper/lowercase conversion for you. It is your responsibility to handle any user prompts: there is no display associated with this command. "Command stacking" is fully supported. If the user types an unrecognized character, Opus will ask him/her to try again. ^OS ... show another file. The REST of the current line is considered the name of a BBS/GBS file. Do *not* include the file's extension. You can include a drive and path. Most settings (eg Color, Auto-More) are maintained across file boundries. If the file you specify doesn't exist, the entire display sequence is ended and the user is returned to Opus. ^OT ... top of file (dangerous: can produce an "endless loop") Useful only for handling "fall-through" menu situations and (with ^B set) for handling niels. (ah-hem) ^OUc ... user response. "C" is a single character. It is the way to process information from the read menu (^OR) command. If the user's most recent respons was not the value you give for `c', the REST OF THE CURRENT LINE is ignored. OPUS Sysop Manual - Page 49 PRIV CONTROL ----------------------------------------------- NOTE: The second character of the commands in this section is a REGULAR ("printable") character ... NOT a control character. Dealing with the rest of the file... ^PD ... Below Disgraced don't see rest of file ^PN ... Below Normal don't see rest of file ^PP ... Below Privil (or Privel) don't see rest of file ^PE ... Below Extra don't see rest of file ^PA ... Below Assistant sysop don't see rest of file ^PS ... Below Sysop don't see rest of file Commands dealing with the rest of the current line... ^PLD ... Below Disgraced don't see rest of line ^PLN ... Below Normal don't see rest of line ^PLP ... Below Privil (or Privel) don't see rest of line ^PLE ... Below Extra don't see rest of line ^PLA ... Below Assistant sysop don't see rest of line ^PLS ... Below Sysop don't see rest of line FIDO<tm> COMPATIBLE QUESTIONAIRE COMMANDS ------------------ Important: All of the functionality in the following --------- commands is available with ^O commands. None of the following are guaranteed beyond Opus Version Zero. Except for some unusual circumstance, you should use the ^O commands instead of these. +nt ... column one only. Signals a multiple choice answer. The `n' is actually a digit. EXAMPLE: `+3' would accept 1, 2, or 3 as an answer. 'T' is normal text. Opus will ask for the answer after the line of text is displayed. The digit is /t ... column one only. 'T' is normal text. After displaying and text, Opus will wait for the user to type some sort of character data. The answer is stored in the answer file. ! ... column one only. If in the most recent multiple choice question (see `+'), the user picked the highest option (eg. `3' above), the questionaire will terminate immediately. OPUS Sysop Manual - Page 50 * ... column one only. Put some user info (eg.name) into the answer file. ?t ... column one only. 'T' is normal text which is not transmitted. Instead, it is stored in the answer file. This command is a Fido<tm> enhancement. It is not guaranteed beyond Opus Version Zero. You should try to use a ^O command instead. Example: Question file: ?NAME /What is your name? Answer file: NAME Mark Twain FOR FILES.BBS ONLY (Fido<tm> compatibility) ---------------- @ ... in column one, stops display for those under AsstSysop. This is for Fido<tm> compatibility only. You should not count on this remaining after Version Zero. Use a ^P command instead. - ... column one only. turns on WHITE. The display will remain white until the next file name. NOTE: There are several ^F commands that deal with the amount of time a user has remaining. Until the user is totally through the logon procedure, he/she will have about 10 minutes. The use of these commands prior to the first MAIN MENU may produce unexpected results. EXAMPLE 1 CONTENTS OF THE EXAMPLE 1 FILE: Please select one of these: H)elp on using the system T)rojan horse program alert E)quipment used on-line Q)uit Select: ^ORhteq ^L ^OUh^OSc:\opus\morehelp ^OUt^OSc:\opus\trojans ^OUq^Oq OPUS Sysop Manual - Page 51 We use an AT computer with a 30 meg Seagate disk drive. The modem is a USR Courier 2400. There is 640k system memory with 3 megabytes of extended memory which is used as a RAM disk. ^OT NOTES FOR EXAMPLE 1: A short menu system for multiple bulletins. First the menu is displayed. Then, after "Select: ", Opus will wait for the caller to type `H', `T', or `A'. For aesthetics, we clear the screen after the menu response (^L). Then.... if the caller typed `H', we will display the file MOREHELP. If it's `T', the caller will see TROJANS. If the caller typed `Q', we will exit the file display and return to Opus. The only unaccounted-for menu response is `E' ... which is taken care of by the material at the end. In other words, if the user gets to the part beginning with "We use an...", he/she must have typed an `E'. It's the "fall-through" case here. Because Opus doesn't have to change to another file, the fall-through will always be the quickest. Finally, at the end of the file, we tell Opus to recycle and display the menu again (^OT). EXAMPLE 2 CONTENTS OF THE EXAMPLE 2 FILE: Welcome to the board, ^F^B. ^OOc:\opus\newusers.txt ^OP What is your occupation? ^ONoccupation Please find your favorite color ... B)lue R)ed M)agenta L)ilac Y)ellow P)uce Type the first letter of your choice: ^ORbrmlyp ^OMchoice ^OUbBlue! really? Wow, that's my favorite color, too! Thanks for taking the time to fill out this questionaire. NOTES FOR EXAMPLE 2: A short survey. First we do a welcome that includes the user's name (^F^B). OPUS Sysop Manual - Page 52 Then we setup an answer file called C:\OPUS\NEWUSERS.TXT. Any responses will be put into this file. Note that the answer file stays open across files ... should you swap files using ^OS. The first item we put into the answer file is the user's name (^OP). It is NOT ever necessary to ask a user "What is your name"... not even a new user. It is easier on the system and the caller to use the ^OP command rather than being redundant. The first question deals with the user's occupation. The display would look like this: What is your occupation? _ Whether an answer is required depends on whether you have used the ^F^U or ^F^V commands. If the caller typed "accountant" then your answer file would contain this line: occupation: accountant The description "occupation" was part of the ^ON command itself. The next piece of business is a multiple choice question. It works exactly like the MENU in example #1 above. The addition is `^OMchoice' to store the user's response in the answer file. For example, if the user selected RED, the answer file would look like this: choice: R Note that if the caller likes BLUE, Opus will get all excited. See the `^OU' statement. We use this line for two reasons: (1)to show that you can get exceedingly (excrutiatingly) clever; and (2)you can combine almost any ^O command. You can have more than one answer file. Every time you use ^OO, the current answer file is closed and the new one opened or created. One side effect involves opening the same file... not advised for normal operation... but that is one way to force Opus to physically write to disk any responses it has buffered. OPUS Sysop Manual - Page 53 For More information on OPUS There are two ways to find out more about the way OPUS works and to get questions aswered. If you are having problems with OPUS, contact one of the InfoNodes. They can be reached at: OPUSinfo Here modem (214) 991-3381 1/113 OPUSinfo There modem (415) 753-3356 1/114 This is for questions involving specific problems. They can give you answers to some of the most commonly asked questions. For general discussions about the usage of OPUS, you should consider subscribing to the OPUS sysop EchoMail area, called MEADOW. Any of the distribution nodes can refer you to a tie-in point for this area. If all else fails, contact Jon Sabol at 124/210 for information pertaining to MEADOW EchoMail connections. MEADOW carries the same copyright as OPUS. You are required to act in a friendly and lawful manner if you participate. We are trying desperately to keep a casual and constructive atmosphere in the OPUS area. If that is not your intent, please do not subscribe to the conference. If you wish to discuss technical aspects of the programs, you are wholeheartedly welcome to join!!! OPUS Sysop Manual - Page 54